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FILTERED APPUCATION-TO-APPLICATION COMMUNICATION 

CROSS-REETERENCE TO RELATED APPLICATIONS 

The present applicatioix claims priority fix^m US provisional application iserial 
number 60/206,776, filed May 2A, 2000, which is incorporated herein by reference ia its 
5 entirety, 

BACKGROUND OF IHE INVENTION 

High computing capacity is achieved by connecting a few servers with the 
same or different fimctionality together to form a server farm. Applications running on 
these servers need to transfer data to one another. A server fern environment is 
10 generally built from servers having different levels of security. In such an environment, 
the secure servers must protect themselves from attacks originating at the servers having 
less security. 

One of the methods to protect sensitive servers from attacks from less trusted 
servers is the xjse of application level jSrcAJvaUs, Application level firewalls generally are 

15 hosts running proxy servers, which do not permit direct traffic between segments of the 
networks, and which perform elaborate logptig and auditing of data traffic passing 
throng them. The proxy applications are software components running on the firewall 
and emulating the real target application Having a proxy application in the way 
negatively impacts tiae perfoimaace of the server ferm as a whole. It also makes the 

20 firewall less transparentj causing compatibility problems. 

Siace firewalls are a separate unit between segments of the network, and since 
they contain complex logic, they generate a substantial delay in the 
application-to-appHcation communications. The more complex and high-level the 



1 



P-3150-US 



filtering, the greater the delay. Purfheimore, firewalls my ca-use a cominimicatioii 
bottleneck aad may add a point of failxire between the applications. Moreover, a server 
farm may have a complex topology with redundant links and parallel configurations. In 
order to maintain the level of security for sm:h a topology, a new jSrewall nxay be added 
5 for each new segment that may be created. 

Moreover, high-level filtering is almost im.possible if the protocol is complex 
or midocumesntedj because the network layers xinder the layer to be inspected need to be 
emulated Therefore, appHcadon-level filtering is currently performed only ou 
well-documented protocols in environments that are less performance-sensitive, 

ID Examples of such well-documented protocols include e-mail protocols, file transfer 
ptxDtocoI (FTP) and hyperte>ct transfer protocol (HTTP). Examples of protocols on 
which high-level filtering is not performed include database transactions, network file 
system (NFS) transactions and remot© procedure call (RFC) transactions. 

Currently application-to-application communication over a network involves 

15 several layers of protocol, for example the seven layers of the open systems 
intercormection (OS!) model. Among their many functions, these layers may enable 
error handling, rearranging packets that arrive in the wrong order^ and multiplexing of 
data fi^om different applications. 

In the near future, apphcation-to appHcation communication may talce place 

20 over an efficient network having multi-channel communication hardware with 
communication protocols mostiy implemented in hardware. Non-limiting examples of 
such network include new system area network (SAN), hifiiuBand network, 
Fiber-Channel network and asynchronous transfer mode (ATM) network, Within these 
networks, it may be almost impossible and generally impractical to provide firewalls 
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able to support the bandwidth and topology of these architectures, It would be 
advantageous to provide a new efficient method to filter applioation-to application 
tcafiic. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The subject matter regarded as Hie inventioti is particularly pointed out and 
distinctly claimed in the concluding portion of the specification. The invention, 
ho'wever^ both as to organization and method of opexationj together with objects, 
5 features, and advantages thereof, may best be understood by reference to ihe following 
detailed description when read with the accompanying drawings in which: 

Figs. 1 A and IB lUustcate a comparison of a standard network in relation to the 
OSI model and an exemplary system according to some embodiments of the present 
invention; 

10 Fig, 2 i5 a schematic illustration of a filt^mg system for nel^vork devices 

according to some embodiments of the present invention; 

Fig. 3 is a schematic illiistration of a filtering system for network devices 
having a filtering server according to some embodiments of the pre&ent invaition; and 

Figs, 4A and 4B show a flowchart diagram of the process of connection and 
15 transaction in an InfiniBand network according to some embodiments of the present 
invention. 

It will be appreciated that for simphcity and clarity of illustration, elements 
shown in the figures have not necessarily been drawn to scale. For example, the 
20 dimensions of some of the elements may be exaggerated relative to other elements for 
clarity. Further, where considered appropriate, reference numerals may be repeated 
among the figures to indicate corresponding or analogous elements. 
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DETAILED DESCRIPTION OF THE PRESENT INVENTION 

In the following detailed description, numeroiis specific details are set forth in 
order to provide a thorougii imderstanding of the invention. HoweveCj it will be 
imd^rstood by those skOled rn the art that the present invention may be practiced without 
5 these specific details* In oth^ instances, well-known methods, procedures^ and 
components have not been described in detail so as not to obscure the present invention, 
Some embodinients of the present invention are directed to a system that 
enables filtered appKcation-to-application communication in a server farm in a 
multi-charmel reliable hardware ^vironmcnt (e,g. InfiniBand). The system may also 
10 improve the performance of apphcation4o-appHcation communication between servers 
in the farm. The implementation of multi-channel reliable communication hardware may 
reduce the number of communication software layers above. 

In some embodim^ts of the present invention a lightweight protocol based 
partly in hardware may replace the existing applicationAransport network layer (layers 
15 4-7) of the OSI model The protocol may enable direct application (user 
space)-to-hardware communication and may enable the implementation of transport 
protocols in hardware, 

Reference is now made to Figs. lA and IB, which illustrates a comparison of 
an exemplary standard-network server and an exemplary multi-channel communication 
20 hardware server according to some embodiments of the present invention. Fig, lA 
illustrates a block diagram of a standard-network server in relation to tiie OSI model. In 
a standard network, a network interfece card (NIC) and a NIC driver are mainly 
associated with the physical layer and the linlc layer layers of the OSI model. 
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The network protocols (e.g. TCP/IP) are maixily associated witli the network 
and transport layers. The upper fotar layer of the OSI model may be associated with 
sockets (e.g. winsock) and application traixsport provider (e.g. netlib). In a 
communication between xisers* there is a flow of data through each layer at one end 
5 down through the layers in that server and, at the other end, when the data arrives, 
another flow of data up through the layers in the receiving server and ultimately to the 
end user. Jn contrajst, in some embodiments of the present invention, a muttt-chaimel 
reliable communication hardware may communicate directly with an application 
associated with the application layer of the OSI model as will be explained below, 

10 Fig IB illustrates a block diagram of a multi-channel communication hardware 

server <MMC HW) in a fast network, which enables a fast filtered 
application-to-application commumcation between servers according to some 
embodiments of the present invention, in these embodiments, multi-channel reliable 
communication hardware 106 may replace the standard network card. 'In relation to the 

15 OSI model, communication hardware 106 may replace the first four OSI layers and 
some functions of the upper OSI layers as well. 

A server 100 may comprise a plurality of applications 102, a plurality of 
application program interfaces (API) and filters (IFF) 104 and m^:Iti-channel 
communication hardware 106. Server 100 may also comprise a kernel agent 108 and 

20 optionally may comprise a security monitor 110, The term "kernel agent" refers to 
software elements in a kernel system, which initialize the hardware elements of the 
kernel system. These software elements may be further adapted to allocate channels, to 
handle errors and the like. 
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CommunicatioxL hardware 106 may provide special commimicatioti capabilities 
of tratisferring data reliably directly fixnn process to process. Non-limiting examples of 
snoh commimicatjoa capabilities include error detection, queuing, memory management, 
multiplexing and security. Therefore, there be a significant iticrease m 
5 application-to-application communication perfoxmance, because these capabilities no 
longer need to be provided in the sojStware part of the application-to-application 
communication. It should be noted that communication hardware 106 may comprise a 
transport communication layer implemmted in hardware and may have kemel-bypas$ing 
capabilities. 

10 Non-limiiiag examples of communication hardware 106 include new system 

area network (SAN) technology, for example virtual interfeces (VT), InfiniBand, 
Fiber-Channel, small computer system intofeoe (SCSI), asynchronous transfer mode 
(ATM) and even modified Ethernet 

IFF 104 may be adapted to execute fiinctions that are executed in a standard 

15 network by the application layer, the presentation layer, the session layer and the 
transport layer as will be described in more details with respect: to Fig. 2. 

Reference is now made to Fig. 2, which is a schematic illustration of a filtering 
system for network devices according to some embodiments of the present mvention, A 
server farm may include servers lOOA and lOOB, where^ for example, server lOOA is 

20 more trusted than server lOOB. Server lOOA may comprise a plurality of applications 
102A, a plurahty APIs and filters (IFF) 104A and multi-channel communication 
hardware 106 A. Server 100 A may also comprise a kernel agent 108 A and optionally 
may comprise a security monitor 1 lOA, 
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Similarly, server lOOB xnay comprise a plurality of applications 102B, a 
phicality of application IFFs 104B and multi-ctiannel communication hardware 106B, 
Server lOOB may further comprise a kernel agent 108B and may optionally comprise a 
secnrity monitor 11 OB. Servers lOOA and lOOB may be connected therebetween via a 
5 multi-channel communication link 101 betwem mxdti-channel communication hardware 
106A and 106B. 

Each application IFF 104 may provide an interface to a particular type of 
application 102, For example, there may be separate ^plication IFPs 104 for sockets 
(e.g. winsock), network driver interface specification (NDIS), remote procedure call 

10 (KPC% network file system (NFS), distributed component object model (DCOM) and 
database applications. Application IFFs 104 may be implemented in software to provide 
an interface between applications 102 and multi-channel communication hardware 106, 
For example, a database application 102 may call object linking and embedding 
database (OLEDB) functions. One of the applications IFF 104 may provide OLEDB 

15 functions to the database application 102 and may implemetit a new protocol that may 
directly access communication hardware 106. 

Each IFF 104 noay include a filter that may filter communication based on a 
predetexmined policy. Since the filter is at the application layer, the filter may inspect 
transactions between applications and reject them or issue an alert if they do not comply 

20 witii high-level, application-specific rules including an illegal or impermissible cHent 
identity. Non-limiting examples of tratisactions on which can be perfoxmed a high-level 
filtering include; 

a) filtering database SQL trazisactions, login, stored procedures; 

b) filtering invocatton of RFC transactions, objects and methods; 
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c) filtering sockets (Winsock, BSD, etc) operations; 

d) filteiing remote logins; 

e) filtering remote file system access commands (Le. file sharing, NFS, CIFS), 
based ou the path and/or the access type (read, write, create, delete, etc); and 

5 f) filtering remote management cotomands (for example, a Web server cannot 

tell an application server to kill a process^ and a Web server cannot tell an 
application server to shut down). 
An example of an API and a filter (IFF) 104 may be a socket application filter 
(socket IFF), wbich is configured according to some embodiments of the present 
10 invention. An example of a socket IFF may be a Wlnsook IFF. The Winsock IFF is 
responsible for filtering Winsock-based applications. The filtering process may be 
performed by intercepting the Winsock API calls. 

Non-limiting examples of data available to a socket IFF include the name of 
the process^ which calls the socket, the requested peer address for connectionj port 
15 nnmbers, the actual data that is received or transmitted, and the total number of open 
coimeclions. Based on tihese inputs, the IFF may decide vrfietiier to silently fail the 
operation^ to alert the system administrator of suspicious activity, to pass the request 
forward or to authenticate the request 

The filter (IFF) may operate in several ways. One way of operation may be 
20 blocking local processes by comparing a process to a list of allowed calling processes. 
The socket library (e.g. Winsock DLL) is mapped to the caUing process address space. 
Therefore, the filter may request the calling process file iaformation and may compare 
the received value to a set of rules to determine whether the calling process is allowed 
to call the socket application. 
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Another way of operation may be by blocking client ports. The filter may 
check the paracaeters of tiie ''connecf' API to receive the destmtion address and port. 
The server address and port number may be tested again3t a set of predetermined 
rules, if the te$t fails, the connection is rejected, 
5 Alternatively, the filter may block server ports. The filter may check the 

"listen" API, i.e. the socket that is used for listening to new coxmections. If the 
listeniag port is not valid according to a predefined filtering policy, the fimction fails. 
Another nxore specific filter may be applied to the "accept" APL Upon accepting a 
connection^ the filter may check die client address. If the address is valid according to 
10 a predefined filtering policy, the connection is accepted. 

Another way for the operation of Winsock IFF may be blocking specific data. 
The filter nxay examine the buffers sent over a comiection (send and receive API). The 
data may be examined according to a predefined filtering policy. The socket IFF may 
manage a set of tables. Non-limiting examples of the tables may include a privileged 
15 processes table having the process name and path and checlcsum and a listening port 
table including port number and maximum allowed connection for server port. Other 
examples may include an approved chent address table including client address and 
maximum allowed connections firom the client, and a data filter table. 

Another example of an API and a filter (IFF) may be a database filter 
20 configured according to some embodiments of the present invention. 

Hie database IFF may regulate communication protocol by intercepting the 
caUs to the database and replacing them with a secure protocol layer. More 
specifically, the filter may be implemented as an OLE-DB provider. Non-limiting 
examples of data available to database IFF include the database user, the transaction 
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type, passwords, and the location of Uie client machine, the records and table data. 
Based on these mptxts^, the filter layer may decide whether to fail the operation. 

The database IFF may locate $pecific users by checJdng the connection packet, 
may identify specific client machines by checking physical connection requests, may 
filter specific transactions by examining the transaction properties or any combination 
thereon. 



The table below specifies what type of data the client may send and the type of 
data available fox the FFL 



Client Sends 


Data available to filter 


Database connection request 


Client physical address, user logio, user 
password. 


Database transaction 


Client physical address, the SQL query 


DCOM method invocation 


Client physical address, GUID, method 


File System request 


Client physical address, folder, file 
attributes, user ED, password. 


Winsock connect reqxiest 


Client physical address, port ntimbers, app 



Applications 102 are identrfied/authenttcated to IFFs 104 before creating a 
connection^ ihus avoiding the problem of TrojanSj, scanniag tools and the exploitation of 
the server appHcation through protocol holes. This may be done by identifyiAg and/or 
authenticating any of the following: 

a) the module name and/or the names of the executable(s); 

b) the location of the executable(s); 

c) the timestamp of the executabl6(s); 

d) the size of the executable(s); and 

e) a hash (e,g. CRC, MD5, SHA) of the executable(s). 
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f) a token and/or a key provided to the applicatioxi and/or to the application 
process by an authentication service and/ot a subnet maoager and/or a domain 
controller. 

It is noted that heteandbelow in the specification as weU as in the claimSj the 
5 term token includes any type of a security token, a secnrity key, a seed or any 
equivalence. 

The high-level filtering explained above might be used in order to ensure that 
allowed applications are not used in a way that compromises secnrity (e.g, by issuing 
illegal transactions). In order to avoid spoofing, the filtering may verify that the logical 
10 user name or resource ttame or resource address orighmting fiom a particular resource 
corresponds to the physical address of that resource and/or to other unique value 
associated with the resource, such as a key, a token or a global unique identifier (GUID). 

The communication betwe^ application IFF 104 and communication hardware 
106 may also need to be secured. One possibility is to force a handshake between 
15 application IPF 104 and communication hardware 106 before opening a connection. In 
this case, communication hardware 106 must contain an authentication mechanisnL 

Another possibility may be to force a handshake between IFF 104A and IFF 
104B when IFF 104A wants to send data to IFF 104B. In this case, standard 
communication hardware 106 as described above may be xised. Yet another possibility 
20 may be that the operating system (OS) ensures that the IFF's 104 and/or other related 
software has not changed. 

Kernel software is generally considered secure. However, when it is necessary 
to ensure that the kernel is secure, it may be advantageous to use the following process: 
When server 100 boots xsp, kernel agent 108 may authenticate itself Tvith communication 
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hardware 106 in a ctiallenge-respoMe process. It may also aixttienticate itself witli m 
aufhenticatioii sm^ice, viuch may be in another machiae. Then, anytime a user process 
on server 100 wants to commxinication with an application on aaother server, it has to 
authenticate itself wilh the kernel agent 108. Once the authentication is complete, kernel 
5 agent 108 may contact comm-unication hardMraxe 106, which issues a chaonel to agent 
108 that is passed on to application IFF 104. Application IFF 104 then uses the channel 
to continue the secure conununication. 

Security monitor 110 may alert other systems that a security breach has 
occurred and that a server is no longer trusted Security monitor 110 may send a 

10 heartbeat to multi-channel communication hardware 106 or to a central management 
service to indicate that all is well, Secmity monitor 1 10 may be implemented as a part of 
the operating system. 

Reference is now made to Fig. 3, which is a schematic illustration of a filtering 
system for network devices having a filtering server according to some embodiments of 

15 the present invention. A server farm may comprise a plurality of servers 100 and an 
authentication server 120. Authentication server 120 may comprise a multi-channel 
hardware communication 106, optionally a kernel agent 108 and an authentication 
service 122 coupled to multi-channel hardware communication 106 and to kernel ^ent 
108. Non-limiting examples of such authentication service include a subnet manager, a 

20 domaiQ controller and a certificate authority (CA). In these embodiments, the 
authenticatton process described hereinabove may be performed on authentication server 
120. Instead of perfomiing the security policies on each of server 100, the system may 
take advantage of the high performance of communication link 101 to perfomi a 
centralized authentication- 
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An application layer filter at IFF 104 may inspect transactions between 
applications 102 and n:Lay request an authentication fi:om authentication server 120. As 
described in relatiotx to Fig. 2, application 102 may be identified and/or atrthenticated to 
application IFF before creating the connection. In another embodiments of the present 
5 invention, the servers may have dedicated multi-channel commnaication hardware for 
authorization pinposes. However, the servers may transfer other data via a standard 
communication link 

Reference is now naade to Figs. 4A and 46, wiich is a flow chart diagram of 
the process of connection and transaction ta InfiniBand network according to some 

10 embodiments of the present invention. In this example, server 100 A is referred as a 
client computer and server lOOB is referred as a server computer. The first stage, which 
is illustrated in block 200, is the initialization of computers lOOA and lOOB. When 
client lOOA and server lOOB boots up (step 201), the operating system of the computers 
may verify that the kernel software elements, i. e, kernel agents 108 are genuine (step 

1 5 202). In addition, Infiniband subnet management software may detect the fabric and may 
allocate partitions, local ID'S and paths (step 203). 

The second stage, which is illustrated in block 205, is the connection 
establishment A client application on cUent computer lOOA may want to establish a 
connection with server application on server computer lOOB. Application 102A may 

20 pass a request together with credentials to IFF 104A (step 204). IFF 1 04A may request a 
token ftom an authentication service (step 206). Alternatively, IFF 104A may request a 
token, a key or a seed fix>m the operating system of client comptiter 100. This operation 
may also be performed at a later stage on a per transaction basis as explained 
hereinbelow. 
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Now, IFF 104A may request a connection to application 102B fiom 
oormmunicadon mamger embedded in the system kernel (step 208), IFF 104A may pass 
title token as a parameta^ to the system kemeL 

The commumcatioii manager of cli^t compiater lOOA may request the 
5 connection from tib.e communication manager of server compnter lOOB (step 210), On 
the server machine, communication manager of computer lOOB may pass the request 
together with the token to IFF 1 04B (step 2 12), 

IFF 104B may determine whether the passed token is genuine and whether the 
source is authorized (step 214). IFF 104B may optionally send a random number back to 
1 0 IFF 1 04A to form a challenge-response authentication. When the authentication is ended 
IFF 104B and communicaaon manager of server computer lOOB may respond to the 
request of client lOOA in any known method (step 216). Optionally, .together with data 
transfer, a session token may be provided by server lOOB to client lOOA (step 217). The 
session token may be used in the following transactions. 
15 As was mentioned hereinabove, the authentication and identification may be 

performed in a separate transaction after the connection has already been established in a 
staadard way. 

Now the connection between application 102A and application 102B may be 
estabHshed, All transactions and data transfer thereJSrom -may flow directly between 
20 application 102A and apphcation 102B without the need for kernel intervention. The 
transaction process is described hereinbelow with respect to block 218. 

Application 102A may issue a transaction fiom application 102B without kernel 
intervention (step 220). IFF 104A may send the transaction to application 102B. If a 
session token is available, IFF 104A may sent the session token to IFF 104B (step 222). 
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IFF 104B may receivo the transaction and may check tihie token md the transaction 
according to a predefined secttdty policy (step 224). If -flie transactioxi is legal, IFF 104B 
may transfer the transaction to application 102B for execiition (step 226), 

5 WMIe certain features of the invention have been illustrated and described 

herein, many modifications, substitutions^ changes, and equivalents wiU now occur to 
those of ordinary skill in the art. It is, therefore, to be understood that the appended 
claims are intended to cover all such modifications and changes as fall witbin the true 
spirit of the invention. 
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